Business enterprises typically maintain data in database. For both legal and business reasons, business enterprises are increasingly becoming sensitive to unauthorized access to data in their databases. One type database system that is commonly used by enterprise businesses is a relational database in which data is organized in rows and columns of one or more tables (or table objects). Accordingly, business enterprises are exploring and implementing a number of mechanisms to prevent inadvertent or unauthorized access to row and/or column data. In a relational database management system (RDBMS), table object privileges granted to a user control whether or not access to the data in the table object is allowed. In general, such privilege control does not conventionally extend to the column-level or the row-level.
One technique for controlling access to data in a table on a column-level or a row-level includes use of a label-based access control (LBAC) mechanism—i.e., unless a label of a user is compatible with a label associated with a row or column of a table, then the data for that row or column is not returned to the user. Business enterprises, however, have generally been less accepting of label-based access control mechanisms due to the restrictive nature of label components, the need to provide a label for rows and columns, the lack of flexibility in terms of what can be expressed within labels.
Business enterprises have turned to more flexible mechanisms—e.g., fine-grained access control (FGAC) mechanisms including views, triggers, Oracle's virtual private database, and so on. Such fine-grained access control mechanisms all have one thing in common—the mechanisms supplement, but do not supplant, access control provided by privileges. That is, if a user has a SELECT privilege on a table, the user has access to all row and column data in the table; with conventional fine-grained access control mechanisms, that access is restricted by the addition of predicates and other logic to reduce the rows (and columns) seen by the user. But, by default, every user with privileges on a table has full access to all row and column data until and unless a fine-grained access control restriction is applied to rows or columns. This leaves open the possibility that a user, with privileges on a table object, can inadvertently be missed or not affected by fine-grained access control mechanisms, and therefore the user may be able to access data that the user would otherwise not be allowed to access.